1장. 남이 만든 거대 모델을 가져다 쓰기

출처: 『AI 엔지니어링』(Chip Huyen 지음) | 원서: AI Engineering (O'Reilly) — 본 입문판은 PDF 원문(1장)에서 직접 풀어 썼다.

코드는 분위기만 — Python·API·import 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

이 장은 책의 큰 그림을 한 바퀴 도는 개요다.

"모델이 어떻게 거대해졌고, 그 위에서 우리가 무엇을 만드는가"를 본다.

0장 용어와 척추가 머리에 있으면 충분히 따라온다.

0. 이 장의 새 단어 (0장에 없는 것만)

0장 용어집에 이미 있는 말(파운데이션 모델·언어 모델·LLM·토큰·자기지도학습·파라미터·멀티모달·임베딩·프롬프트 엔지니어링·RAG·파인튜닝·환각·평가·벤치마크)은 다시 풀지 않는다.

이 장에서 처음 나오는 말 3가지만 미리 풀어 둔다.

자기회귀 언어 모델 / 마스크 언어 모델 (autoregressive LM / masked LM)

한 문장 뜻 — 다음 글자를 맞히는 두 가지 방식. 앞만 보고 맞히면 자기회귀, 앞뒤를 다 보고 가운데 빈칸을 맞히면 마스크.

일상비유 — 끝말잇기 vs 빈칸 채우기. 끝말잇기는 앞 글자만 보고 다음을 잇는다(자기회귀). 빈칸 채우기는 문장 전체를 보고 가운데를 메운다(마스크).

한 줄 예 —

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 자기회귀: 앞만 보고 다음 한 글자
model.next("내가 좋아하는 색은")        # → "파란색"
# 마스크: 앞뒤 다 보고 가운데 빈칸
model.fill("내가 좋아하는 ___은 파란색") # → "색"

3계층 스택 (application / model / infrastructure)

한 문장 뜻 — AI 앱을 떠받치는 세 층. 위부터 앱 개발, 모델 개발, 인프라.

일상비유 — 식당 한 채. 손님이 보는 홀(앱 개발), 요리하는 주방(모델 개발), 전기·수도·건물(인프라). 대부분의 일은 홀에서 일어난다.

한 줄 예 —

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
stack = ["앱 개발", "모델 개발", "인프라"]  # 위 → 아래
# AI 엔지니어링의 무게중심은 맨 위 "앱 개발"

방어 가능성 (defensibility)

한 문장 뜻 — 경쟁사가 내 제품을 쉽게 따라 만들지 못하게 막는 힘.

일상비유 — 성을 둘러싼 해자. 해자가 깊을수록 적이 못 넘어온다. AI는 누구나 쉽게 만들 수 있어 해자 파기가 더 중요해졌다.

한 줄 예 —

# 아래 예제는 핵심 흐름만 짧게 보여 줍니다.
# 내 데이터가 쌓일수록 따라잡기 어려워짐 = 해자
moat = collect_user_data()  # 남이 못 가진 사용 기록

이 장에서 딱 4가지만 (TL;DR)

1. 모델이 거대해진 길은 한 줄로 요약된다. 언어 모델 → 자기지도학습으로 LLM → 멀티모달 더해 파운데이션 모델.
2. 그 거대 모델을 만드는 게 아니라 가져다 부리는 일이 AI 엔지니어링이다. 세 가지 힘(범용 능력·투자·낮아진 진입장벽)이 이 분야를 폭발시켰다.
3. 활용 사례는 8가지(코딩·이미지영상·글쓰기·교육·대화형봇·정보집계·데이터체계화·워크플로자동화)로 묶인다. 하지만 데모는 쉽고 진짜 제품은 어렵다.
4. AI 앱은 3계층(앱 개발·모델 개발·인프라)으로 떠받쳐지고, 무게중심은 맨 위 앱 개발이다. 이게 ML 엔지니어링과 갈리는 지점이다.

1. 왜 지금 'AI 엔지니어링'인가

망가지는 장면

"AI 한다고 했더니 다들 '모델을 처음부터 학습시키는 거냐'고 묻는다."

그건 구글·오픈AI 같은 소수만 하는 일이다.

대다수는 그 모델을 가져다 쓸 뿐이다.

저자는 이 흐름을 한 문장으로 못 박는다.

AI 앱 수요는 늘었고, AI 앱 만드는 진입장벽은 낮아졌다.

그래서 "남이 만든 모델 위에 앱을 얹는 일", 즉 AI 엔지니어링이 가장 빠르게 크는 분야가 됐다.

코드 한 장면

옛날엔 모델을 직접 키워야 했다. 지금은 콘센트에 플러그 꽂듯 불러 쓴다.

# 옛날: 데이터 모으고, GPU 돌리고, 몇 달 학습 (소수만 가능)
# 답변을 생성할 LLM 클라이언트나 모델 설정을 준비합니다.
my_model = train_from_scratch(huge_data, gpus=1000)

# 지금: 남이 만든 모델을 한 줄로 불러 씀
# `answer`에 중간 결과를 담아 다음 줄에서 재사용합니다.
answer = api.call("foundation-model", "이 문장 영어로 번역")

1.1 언어 모델은 어떻게 거대해졌나

일상비유 — 정답표 만들기 vs 글이 곧 정답.

옛날 방식(지도학습)은 사람이 정답표를 손으로 만들었다.

이미지 100만 장에 "고양이/개" 라벨을 붙이는 데만 5만 달러.

자기지도학습은 이 벽을 넘었다.

문장 하나가 스스로 문제이자 정답이 된다.

'I love street food' 한 문장이 6개의 학습 문제를 만든다.

입력                          → 출력(다음 토큰)
<BOS>                        → I
<BOS> I                      → love
<BOS> I love                 → street
<BOS> I love street          → food
<BOS> I love street food     → <EOS>

<BOS>와 <EOS>는 문장의 시작·끝 표시다.

끝 표시는 모델이 "여기서 답을 멈춰라"를 아는 데 쓰인다.

한 문장 정의 — 자기지도학습은 데이터 자체에서 다음 토큰을 정답으로 뽑아 쓰는 방식이며, 덕분에 사람이 채점 안 해도 인터넷 규모로 모델을 키웠다.

참고 (지금 몰라도 됨) — 자기지도학습은 데이터에서 정답을 추론한다. 정답이 아예 필요 없는 비지도학습과는 다르다.

모델 크기는 상대적이다.

최초 GPT(2018)는 파라미터 1.17억 개로 '대규모'였다.

GPT-2(2019)가 15억 개로 나오자 곧장 '소규모'가 됐다.

책 집필 시점엔 1,000억 개가 '대규모'다.

예시 — 두 가지 언어 모델 비교.

worked-example: 자기회귀는 "내가 좋아하는 색은 ___"에서 뒤를 잇는다.

부분완성: 마스크는 "내가 좋아하는 ___은 파란색"에서 가운데 빈칸을 채운다. 빈칸 답은? → "색".

독립적용: "코드 디버깅"은 앞뒤 코드를 다 봐야 오류가 보인다. 어느 쪽이 어울릴까? → 앞뒤를 보는 마스크.

언어 모델은 결국 완성 기계다.

"사느냐 죽느냐"를 넣으면 "그것이 문제로다"로 잇는다.

번역·스팸 분류·코딩도 다 '완성'으로 처리한다.

단, 완성은 확률로 고른 거라 사실이 틀릴 수 있다.

1.2 LLM에 눈·귀를 달다 (파운데이션 모델)

망가지는 장면

"글만 읽는 모델은 사진 한 장 못 본다. 그런데 세상은 글로만 되어 있지 않다."

사람은 글·시각·청각으로 세상을 안다.

그래서 LLM에 이미지·음성·영상까지 붙인 게 파운데이션 모델이다.

일상비유 — 글만 읽던 사람 vs 오감을 쓰는 사람.

예시 — CLIP(OpenAI, 2021).

worked-example: 이미지마다 사람이 라벨을 달면 너무 비싸다.

부분완성: 그래서 인터넷에서 (이미지, 글)이 같이 붙어 있는 쌍을 그냥 긁어모았다. 비용은? → 거의 0.

독립적용: 그렇게 모은 데이터는 이미지넷보다 몇 배 컸을까? → 400배(4억 쌍).

CLIP은 글과 그림을 같은 의미 좌표로 바꾸는 임베딩 모델이다.

생성 모델이 아니라, 멀티모달 모델의 부품으로 쓰인다.

파운데이션 모델 vs 작업 특화 모델.

'사서 쓸까, 직접 만들까'는 팀이 정할 문제다.

1.3 AI 엔지니어링을 키운 세 가지 힘

일상비유 — 불을 키우는 세 가지: 땔감·돈·낮은 문턱.

예시 — 진입장벽이 얼마나 낮아졌나.

worked-example: 옛날엔 모델을 직접 호스팅할 인프라가 있어야 썼다.

부분완성: 지금은 무엇 한 번이면 강력한 모델을 쓸까? → API 호출 한 번.

독립적용: 코드를 한 줄도 못 짜는 사람도 앱을 만들 수 있을까? → 그렇다. AI가 코드를 대신 짜 주니까.

왜 'AI 엔지니어링'이라는 이름인가.

ML 엔지니어링·MLOps·LLMOps 등 후보가 많았다.

저자는 20명에게 물었고, 다수가 'AI 엔지니어링'을 골랐다.

ML 엔지니어링은 모델 개발에 방점이 있어 '활용' 중심인 이 일을 다 담지 못한다.

성장 지표. 오픈소스 도구 4개(AutoGPT·LangChain·Stable Diffusion WebUI·Ollama)가 2년 만에 깃허브에서 비트코인보다 별을 더 많이 받았다.

미니 시나리오 — 친구가 "나 코딩 하나도 모르는데 AI 앱 만들 수 있어?"라고 묻는다. 답: "응. 모델은 가져다 쓰는 거라 API만 부르면 되고, 코드도 AI가 짜 줘. 만드는 게 어려운 게 아니라 잘 만드는 게 어려운 거야."

2. 무엇을 만들 수 있나 (활용 사례 8가지)

저자는 오픈소스 AI 앱 205개를 8개 그룹으로 나눴다.

비율이 작다고 인기가 없는 건 아니다. 오픈소스로 안 풀렸을 뿐(기업용에 더 적합).

예시 — 코딩에서 AI가 잘하는 일과 못하는 일.

worked-example: 맥킨지 연구 — 코드 문서화는 생산성 45~50%↑.

부분완성: 그럼 매우 복잡한 작업은? → 효과 10% 미만.

독립적용: AI가 소프트웨어 엔지니어를 없앨까? → 아니다. 역할이 바뀔 뿐이다. (AI는 백엔드보다 프런트엔드에 더 강하다.)

글쓰기의 그늘.

AI는 SEO(검색 최적화)를 너무 잘한다.

그래서 저질 글 공장이 생겼다.

뉴스가드(2023)는 AI 생성 저품질 사이트에서 유명 브랜드 광고 400개 가까이를 발견했다.

미니 시나리오 — 기업이 새 앱을 고를 때 보통 어느 쪽을 먼저 도입할까? 외부용(고객 챗봇)? 내부용(사내 지식 관리)? → 내부용이다. 데이터 유출·규정 위험이 작아서다. 실험 중 절반 넘는 기업이 실제로 배포한 건 '텍스트 요약'과 '사내 지식 관리'였다.

3. 데모는 쉽고, 진짜 제품은 어렵다 (기획)

망가지는 장면

"주말에 만든 데모는 멋지게 돌았다. 그런데 사용자에게 내놓자 엉뚱한 답·거짓 답이 쏟아진다."

파운데이션 모델은 시작이 쉽다.

하지만 믿고 쓸 제품까지가 멀고 험하다.

일상비유 — 사진용 한 접시 vs 매일 같은 맛 내는 식당.

3.1 첫 질문 — 왜 만드는가

기업이 AI를 만드는 이유는 위험 높은 순으로 셋이다.

1. 비즈니스 연속성 — AI 가진 경쟁사에 밀려 생존 위협. 2023년 가트너 조사에서 7%가 이 이유.
2. 이익·생산성 증대 — 카피·고객지원·영업 리드 개선. 대부분의 기업.
3. 기술 흐름 팔로우 — 뒤처질까 봐. 코닥·블록버스터·블랙베리를 떠올리면 됨.

AI와 사람의 역할 (애플 프레임워크).

예시 — 역할에 따라 기준이 달라진다.

worked-example: AI가 핵심이면(Face ID) 더 정확해야 한다.

부분완성: AI가 보완적이면(스마트 작성) 사람들은 실수에 더 ___하다. → 관대.

독립적용: 선제형은 사용자가 안 시켰는데 먼저 끼어든다. 품질 기준은 더 높을까 낮을까? → 더 높다(별로면 성가시니까).

사람이 얼마나 끼어드는지는 휴먼 인 더 루프로 조절한다.

마이크로소프트의 크롤-워크-런: 크롤(사람 필수) → 워크(내부 직원과 AI) → 런(외부 사용자와 AI).

3.2 기대치 설정

성공을 어떻게 잴지 먼저 정한다.

고객 지원 챗봇이라면: 자동화 비율? 처리량? 응답 속도? 인력 절감?

최소 성능 기준: 품질 / 지연(첫 응답까지 시간 등) / 비용 / 기타(공정성).

3.3 마일스톤 — 마지막 구간이 제일 멀다

기존 모델이 이미 30%를 처리하면, 60% 목표까지 남은 일이 절반으로 준다.

잘못된 예 — "데모 잘 되니 제품도 금방."

올바른 예 — 마지막 구간(60→100)의 어려움을 계획에 넣는다.

링크드인(2024): 80%까지 1개월, 95% 넘기는 데 추가 4개월.

"0에서 60은 쉽지만, 60에서 100은 매우 어렵다."

3.4 유지보수 — 총알 열차에 올라타는 일

3.5 방어 가능성 — 해자 파기

진입장벽이 낮은 건 축복이자 저주다.

내가 쉽게 만들면 경쟁사도 쉽게 만든다.

예시 — 세 가지 경쟁 우위.

worked-example: 기술력은? → 다들 같은 파운데이션 모델 쓰니 차별화 어렵다.

부분완성: 유통력은 누가 유리? → 대기업.

독립적용: 그럼 스타트업의 해자는? → 데이터 우위. 먼저 진출해 사용 데이터를 쌓는 '데이터 플라이휠'.

미니 시나리오 — 구글 독스 기능으로 흡수될 만한 작은 제품을 만든다. 구글이 엔지니어 3명으로 2주 만에 베낄 수 있다면? → 데이터 해자가 없으면 위험하다. 단, 캘린들리·메일침프처럼 '큰 제품의 기능'으로 시작해 경쟁사를 넘은 사례도 많다.

4. AI 앱을 떠받치는 3계층 (스택)

일상비유 — 식당 한 채.

┌──────────────────────────────────────────┐
│  앱 개발 (홀)                              │
│  프롬프트 · 컨텍스트 구성 · 평가 · AI 인터페이스 │
│  ← 무게중심 / 가장 빠르게 성장             │
├──────────────────────────────────────────┤
│  모델 개발 (주방)                          │
│  모델링·학습 · 파인튜닝 · 추론 최적화 · 데이터셋 │
│  ← 전통 ML 엔지니어링과 가장 가까움         │
├──────────────────────────────────────────┤
│  인프라 (전기·수도·건물)                    │
│  서빙 · 컴퓨팅·데이터 관리 · 모니터링         │
│  ← 변화 가장 느림 (핵심 요구는 그대로)       │
└──────────────────────────────────────────┘

2024년 깃허브 분석(별 500↑ 저장소 920개): 가장 빨리 큰 건 앱 개발 계층.

인프라 성장은 작았다. 서빙·모니터링 같은 핵심 요구는 안 바뀌니까.

4.1 AI 엔지니어링 vs ML 엔지니어링

세 가지 핵심 차이:

1. 누가 모델을 학습하나 — ML은 직접 학습. AI는 가져다 조정(프롬프트·파인튜닝).
2. 모델 규모 — 파운데이션 모델은 크고 느려서 추론 최적화 압박이 크다.
3. 개방형 출력 — 스팸 분류는 정답이 둘(스팸/정상)이라 채점이 쉽다. 챗봇 답은 정답이 무한해 채점이 어렵다. → 평가가 훨씬 중요해진다.

모델 조정 두 가지.

예시 — 가중치를 바꾸나 안 바꾸나.

worked-example: 프롬프트 엔지니어링은 모델을 그대로 두고 지시만 바꾼다. → 가중치 안 바뀜.

부분완성: 파인튜닝은 모델 가중치를 ___한다. → 바꾼다(추가 학습).

독립적용: "일기를 입력해 챗봇에게 내 어린 시절을 흉내 내게 했다"는 학습일까? → 아니다. 컨텍스트로 시킨 거라 프롬프트 엔지니어링이다.

학습 단계 세 가지.

• 사전 학습 — 처음부터 학습(가중치 무작위 시작). InstructGPT 기준 자원의 98%. 소수만 가능.
• 파인튜닝 — 이미 학습된 모델을 추가 학습. 자원 훨씬 적게 듦.
• 사후 학습 — 사전 학습 뒤 단계. 누가 하느냐로 구분 — 제공업체가 하면 사후 학습, 앱 개발자가 하면 파인튜닝.

예시 — 평가는 왜 어려운가 (제미나이 사례).

worked-example: 구글은 제미나이가 MMLU에서 챗GPT보다 낫다고 했다.

부분완성: 그런데 제미나이엔 32번 풀어 다수결(CoT@32), 챗GPT엔 예시 5개(5-샷)만 줬다. 같은 조건이었을까? → 아니다.

독립적용: 같은 5-샷으로 다시 비교하면? → 챗GPT가 더 높았다. 그래서 공정한 채점 기준이 필수다.

4.2 AI 엔지니어링 vs 풀스택 엔지니어링

인터페이스가 중요해지며 AI 엔지니어링은 풀스택 개발에 가까워진다.

전통 ML은 파이썬 중심이었지만 LangChain.js·Vercel AI SDK 등 자바스크립트 지원이 는다.

워크플로가 뒤집혔다.

제품을 먼저 만들고, 가능성이 보일 때만 데이터·모델에 투자한다.

단순 규칙

복잡하면 이 한 줄만 들고 가면 된다.

모델은 가져다 쓰는 것. 만드는 게 어려운 게 아니라 잘 만들었는지 채점하는 게 어렵다.

세부 규칙: - 모델을 직접 학습할지 가져다 쓸지 고민되면 → 대부분 가져다 쓰는 게 맞다(AI 엔지니어링). - 가중치를 안 바꾸고 시작하고 싶으면 → 프롬프트 엔지니어링부터. - 데모가 잘 됐다고 제품 다 됐다고 믿지 말 것 → 마지막 구간(60→100)을 계획에 넣는다.

한 걸음 더 ▸ (지금 몰라도 됨) — 파인튜닝과 사후 학습이 기술적으로 거의 같은데 왜 다르게 부르는지, 추론 최적화를 실제로 어떻게 하는지는 더 깊은 주제다. 지금은 "조정엔 가중치를 안 바꾸는 길(프롬프트)과 바꾸는 길(파인튜닝)이 있다"만 기억하면 된다.

정리

• 언어 모델 → 자기지도학습으로 LLM → 멀티모달 더해 파운데이션 모델. 이게 거대화의 길이다.
• 그 모델을 가져다 부리는 일이 AI 엔지니어링이고, 무게중심은 3계층 중 맨 위 '앱 개발'이다.
• 활용 사례는 8가지로 묶이지만, 공통 진실은 하나 — 데모는 쉽고 진짜 제품은 어렵다.

다음 장 예고 — 다음 장에서는 이 파운데이션 모델의 속을 연다. 어떻게 학습되고, 왜 확률로 답하는지를 본다. (지금 몰라도 됩니다.)

연습문제

1. 설명. 남이 만든 거대 모델을 가져다 쓰기의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
2. 구분. 두 개념(ML 엔지니어링, AI 엔지니어링)을 실제 예시 하나로 구분하라.
3. 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

부록 B. 헷갈리는 개념 비교표

부록 C. 더 읽을 자료

• 이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
• 같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
• 원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
• 이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

1. 설명 예시. 남이 만든 거대 모델을 가져다 쓰기는 거대 모델을 제품에 넣을 때 어떤 선택을 하고 어떻게 확인할지 판단하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
2. 구분 예시. 두 개념(ML 엔지니어링, AI 엔지니어링)의 차이는 이렇게 잡으면 된다. ML은 모델을 직접 학습하는 쪽, AI 엔지니어링은 큰 모델을 제품에 맞게 부리는 쪽이다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
3. 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.